Driving different types of user interfaces with a single backend view controller

ABSTRACT

Disclosed herein are system, method, and computer program product embodiments for driving multiple user interfaces using a backend view controller. A view interface system that is capable of displaying multiple user interfaces of different view formats may receive a data set request to display a data set in a particular view format. The view interface system may then transmit, to the backend view controller, the data set request and receive an indication that the data set is exposed by the backend view controller. Based on the indication, the view interface system may perform data binding of the data set to interface objects associated with the view format to form a user interface based on the view format and display the user interface.

BACKGROUND

Current user interface frameworks use multiple intermediary controllersto separate data from the user interfaces used to view that data. Theintermediary controllers are typically installed on the same device asthe user interface (e.g., a client device) and connect the data to theuser interfaces by exchanging data with a data source, and formattingthe data to be displayed by the user interfaces. Different types of userinterfaces such as a two-dimensional or three-dimensional interface eachrequires a separate intermediary controller that supports that specificinterface. While this implementation generally may reduce the amount ofprogramming required for the user interface, intermediary controllersstill must be developed to work with the different user interfaces andrequire additional programming in order to maintain compatibility withexisting user interfaces when they are updated. Intermediary controllersare specific to each user interface and must be installed on each userdevice which could lead to inconsistent views across different userdevices if each user device has a different intermediary controller fora specific user interface.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and form a partof the specification, illustrate embodiments of the present disclosureand, together with the description, further serve to explain theprinciples of the disclosure and to enable a person skilled in therelevant art(s) to make and use the embodiments.

FIG. 1 is a block diagram of an environment including a user interfacearchitecture, according to some embodiments.

FIG. 2 is a block diagram of a user interface architecture, according tosome embodiments.

FIG. 3 is a flowchart illustrating a method of driving multiple userinterfaces using a backend view controller.

FIG. 4 is an example computer system useful for implementing variousembodiments.

In the drawings, like reference numbers generally indicate identical orsimilar elements. Additionally, generally, the left-most digit(s) of areference number identifies the drawing in which the reference numberfirst appears.

DETAILED DESCRIPTION

Provided herein are system, apparatus, device, method and/or computerprogram product embodiments, and/or combinations and sub-combinationsthereof, for driving multiple user interfaces using a single backendview controller.

A user interface framework may employ a backend view controllerimplemented on a backend device that is remote from a user device thatincludes a view interface system. The view interface system may be usedfor providing a user interface that displays data from a data source.The backend view controller may act as a conduit between the viewinterface system and the data source by translating inputs from the viewinterface system into commands for manipulating or retrieving data fromthe data source.

By shifting the backend view controller to a backend device (instead ofbeing implemented on the user device), a single backend view controllermay be used to support multiple view formats of user interfaces becausethe backend view controller on the backend device is able to maintain ashared user interface state across multiple user interfaces. In otherwords, there may be a many-to-one relationship between the number ofuser interfaces provided at a user device (i.e., many) and the number ofview controllers necessary to support each interface (i.e., one). Thisis in contrast to when the view controller is implemented on a userdevice. In such implementations, a separate view controller is neededfor each view format and must be implemented on each user device.

Implementing the backend view controller on a backend device alsoenables a common view between multiple user devices even if the userdevices utilize different view formats for their user interfaces becausethe backend view controller utilizes the same data set to maintain thesame user interface state across the user interfaces no matter whichdevices are attempting to access the data.

One example of a view controller is a ViewModel construct implementedwithin the Model View ViewModel (MVVM) design scheme. One example of aview interface system is a View construct of MVVM. A data source mayinclude or provide an interface or business logic that exposes the datato the view controller. One example of such an interface is the Modelconstruct of MVVM. The interface includes processes or functions thatmay be executed by view controller in order to access data of the datasource. The user interface framework may implement the view controlleron a backend device and the view interface system on a client device.The client device may be any device that is separate or remote from thebackend device, such as any device operated by a user.

The backend device may be any device that acts as a data source thatstores data to be provided to the view interface system. Examples ofsuch backend devices include but are not limited to servers, datasources, data lakes, data silos, message streams, relational databases,semi-structured data (CSV, logs, xml, etc.), unstructured data, binarydata (images, audio, video, etc.), or other suitable stored data, bothon-premises and on the cloud. By implementing the view controller in thebackend closer to the data source, the view controller may dynamicallyexpose the data from the data source in a variety of differentinterfaces. Accordingly, the user interface framework may employ asingle view controller for providing different types of user interfacesto the view interface system.

The view interface system may utilize data binding to establish aconnection between the user interface and the data source based on thedata that is transported to and from the data source. This way, a singleimplementation of the view controller may be used for presentingmultiple view formats such as a two-dimensional interface,three-dimensional interface, and a virtual reality interface, just toname a few examples, even when using different user interfacetechnologies. Bi-directional communication channels may be establishedbetween the view interface system and the view controller to transferdata. After binding the view interface system and the view controller,updated data may also be transferred through the bi-directionalcommunication channels.

As noted above, employing a single view controller reduces developmentefforts to support multiple user interface technologies by being able tosupport a shared user interface state across multiple view formats foruser interfaces. For example, the same data set from a data source thatis selected in a two-dimensional view format (or interface) can beviewed simultaneously in a virtual reality scene or vice versa. Thisfunctionality is enabled because the state of the user interfaceprovided by the view interface is no longer replicated by the differentview controllers implemented at the user device, but instead by acentrally implemented view controller on a backend device. Thebi-directional communication channels ensure a consistent transport ofthe data to and from the view interface.

Data visualization across multiple view formats in user interfaces canbe challenging based on the immense amount of data that is generallyavailable through data sources. Data visualization should be flexiblewith regards to the visualization methods chosen to view the data bybeing able support multiple view formats, such as two dimensional (2D),three dimensional (3D), and virtual reality (VR) on the same device andthrough the same application. View formats may also be referred to as atype of user interface.

Accordingly, embodiments of this disclosure allow a backendvisualization system to provide multiple view formats to front-enddevices using a single view controller. These features of exampleembodiments will now be discussed in greater detail with respect to thecorresponding figures.

FIG. 1 is a block diagram illustrating environment 100 having backenddevice 110, and user devices 150 a-n for providing multiple userinterfaces within a user interface architecture, according to someembodiments. Any operation herein may be performed by any type ofstructure in the diagram, such as a module or dedicated device, inhardware, software, or any combination thereof. Any block in the blockdiagram of FIG. 1 may be regarded as a module, apparatus, dedicateddevice, general-purpose processor, engine, state machine, application,functional element, or related technology capable of and configured toperform its corresponding operation(s) described herein. Environment 100includes backend device 110, data source 120, data hub 130,communication channel 140, and any number of user devices 150 a-n.

Backend device 110 may be implemented as any number of data storagesystems storing data. Backend device 110 includes data source 120 whichmay be a database management system or relational database tool. Datasource 120 may further be a message queue or stream processing platformsuch as Apache Kafka or Apache Spark or other data storage systems likeApache Hadoop, HDFS, or Amazon S3, to name just some examples. Datasource 120 may be a data lake, data silo, semi-structured data system(CSV, logs, xml, etc.), unstructured data system, binary datarepository, or other suitable repository. Data source 120 may beimplemented as a one or more devices.

Data source 120 may include state 121 which may reflect the currentcircumstances of data stored by data source 120. State 121 reflectschanges from user devices 150 a-n of data source 120. In an embodiment,state 121 may be represented by an appropriately formatted tuple, e.g.,using JSON, XML, or other human readable transfer protocol. When state121 changes, either based on a change to data source 120, the receptionof inputs from data hub 130 or user devices 150 a-n, data hub 130 maypropagate the changed data to view interfaces 151 a-n which may havebeen bound (through a data-binding process discussed below) to datasource 120 through backend visualization system 131. In an embodiment,data hub 130 may transmit only a delta, i.e., the differences between acurrent state as compared to a previous state, of changed data in thestate to the other front-ends to improve the efficiency of thetransaction. Because backend visualization system 131 is implemented onbackend device 110, it is capable of maintaining a consistent state 121across multiple user interfaces that are accessing data source 120. Thismeans that the same data set may be used across any number of (or all)user interfaces of different view formats and across different userdevices 150 a-n.

Backend device 110 also may include data hub 130 which orchestrates datafrom data source 120 capable of combining structured and unstructured(e.g., data in natural language format) data. Data hub 130 may processdata such as transforming, converting, modifying, managing, analyzing orotherwise interacting with data from data source 120, and may providethe processed data to a user interface. Exemplary operations conductedwithin data hub 13 may include, but are not limited to: converting datafrom one format to another, preparing data for visualization, organizingthe data, mining the data using regular expressions, natural languageprocessors, or other mechanism, sharing data between different webapplications, editing video/audio files, and/or any of a myriad ofsuitable interactions. In an embodiment, data hub 130 executes theseoperations in real-time using parallel and distributed processing,channels, pipelines, and other big-data manipulation techniques.

Data hub 130 may include backend visualization system 131 which may actas an interface between data source 120 and view interfaces 151 a-n. Inanother embodiment, backend visualization system 131 may be implementedseparately from data hub 130 as another component of backend device 110.Backend visualization system 131 may receive commands from any one ofuser devices 150 a-n, retrieve data from data source 120, and processthe retrieved data based on preconfigured properties which may then bedisplayed by one of view interfaces 151 a-n. Backend visualizationsystem 131 exposes navigation and manipulation functionality to viewinterfaces 151 a-n to navigate and manipulate data provided by datasource 120.

Data hub 130 may incorporate data processing pipelines and othertransformational approaches to provide advance analytics and intelligentdata based on the contents of data source 120. Data hub 130 may runvarious predefined or custom-built functions, referred to herein asoperations, against the data to transform, organize, and analyze thedata and/or perform additional programmatic functions with the data.Data hub 130 may present the manipulated (or raw) data, derivedanalytics, visualizations, and other results to a user interfaceprovided by view interfaces 151 a-n which are located at user devices150 a-n, respectively. After performing data binding with backendvisualization system 131, view interfaces 151 a-n may receive, pull, andorganize data from data source 120 through backend visualization system131. Data binding may include two-way binding and declarative databinding using binding expressions. Two-way binding enables viewinterfaces 151 a-n to be bound to backend visualization system 131 andvice versa. Accordingly, when properties in the data set are changed,user interface components in view interfaces 151 a-n that are bound tothat particular data set are updated. Similarly, when user interfacecomponents in view interfaces 151 a-n are updated, those changes aresent to the data set.

Communication channel 140 may be a wired and/or wireless pipeline orconnection between data source 120, data hub 130, and backendvisualization system 131, and other components in backend device 110.Communication channel 140 may transmit data using any suitable transferprotocol, communication protocol, or other mechanism. Communicationchannel 140 may provide a way to connect different, concurrentoperations, functions, data source 120, and backend visualization system131. In an embodiment, communication channel 140 may be bi-directional,i.e., used to both send and receive data between backend device 110 anduser devices 150 a-n. Although communication channel 140 is illustratedin the example of FIG. 1 as a single channel, one skilled in therelevant art(s) will understand that communication channel 140 mayrepresent two or more channels providing communications between backenddevice 110 and user devices 150 a-n. Updates to data in data source 120may be communicated through communication channel 140 to any viewinterfaces that have initiated data binding with that data such that theupdates can be displayed using the appropriate view interface. In thismanner, data binding essentially allows various user interfacecomponents of view interfaces 151 a-n to subscribe to and be associatedwith certain data provided by backend visualization system 131. In anembodiment, communication channel 140 may be implemented as a websocketconnection.

User devices 150 a-n may be implemented as any device that can becontrolled by an end user such as but not limited to a personal digitalassistant, desktop workstation, laptop or notebook computer, netbook,tablet, smart phone, mobile phone, smart watch or other wearable,appliance, part of the Internet-of-Things, and/or embedded system, toname a few non-limiting examples, or any combination thereof. Userdevices 150 a-n may be managed or otherwise controlled by business,organization, or other suitable group.

User devices 150 a-n may include view interfaces 151 a-n, respectively.In an embodiment, view interfaces 151 a-n are composed of visualcomponents that present data received from backend device 110 in aspecified format. Backend visualization system 131 provides a set ofviews (or interfaces) that correspond to a visual component in the viewinterface. View interfaces 151 a-n may utilize data-binding to bindvisual components to the interfaces provided by backend visualizationsystem 131. View interfaces 151 a-n may be considered visual containersfor presenting certain data provided by data source 120 through backendvisualization system 131.

Because view interfaces 151 a-n are accessing the same data set, even ifthey are utilizing different view formats through the same backendvisualization system, view interfaces 151 a-n operate to present acommon view of the data set which facilitates collaboration across userdevices 150 a-n.

FIG. 2 is a block diagram illustrating a user interface architecture 200having backend visualization system 210, user device 220, andcommunication channel 230. The implementation provided in FIG. 2 ismerely exemplary, and one skilled in the relevant art(s) will appreciatethat many approaches may be taken to provide a user interfacearchitecture 200 in accordance with this disclosure. Backendvisualization system 210 and user device 220 of user interfacearchitecture 200 may be representative of backend visualization system131 and any one of user devices 150 a-n described in reference toFIG. 1. Backend visualization system 210 may include model 211 and viewcontroller 212, and user device 220 may include view interface 221 whichmay include a two-dimensional (2D) interface 222, three-dimensional (3D)interface 223, and virtual reality (VR) interface 224, which arerepresentative of user interfaces provided in those formats.

Model 211 provides support for different views of data from a datasource (e.g., data source 120) that may be accessed by view interface221 in user device 220. In an embodiment, model 211 may include businesslogic that exposes functions that may be performed on the data of thedata source. In another embodiment, model 211 may be separate the thebusiness logic. Model 211 may act as a gateway between data in a datasource and view controller 212.

View controller 212 and view interface 221 communicate via data-binding,method calls, properties, and notifications (or events) associated withdata that is to be provided by view controller to view interface 221through model 211. This may be accomplished by view controller 212exposing methods, commands, properties of data, and other functions thatmay include, among other things: maintain the state of interfacesprovided by view interface 221, manipulate model 211 (and the underlyingdata from a data source) based on inputs received by view interface 221,and transfer notifications of updated data to view interface 221 if databinding has been performed. Interaction between view controller 212 andmodel 211 may be implemented through interfaces in view controller 212that enable retrieval and manipulation of data through model 211.

View controller 212 may establish data binding with any number of viewadapters that support multiple view formats for user interfaces. In anembodiment, the view adapters are installed on user device 220, such aspart of view interface 221. In another embodiment, the view adapters maybe installed in view controller 212. Examples of view adapters includebut are not limited to two-dimensional (2D) adapter 213 for supportingtwo-dimensional interfaces, three dimensional (3D) adapter 214 forsupporting three-dimensional interfaces, and virtual reality (VR)adapter 215 for supporting virtual reality interfaces. As new viewformats are created, specific adapters that support those new formatsmay be installed in view interface 221 221 to update the functionalityof view interface 221.

View interface 221 provides a structured user interface for displayingdata that is provided through backend visualization system 210. Viewinterface 221 may receive inputs from a user of user device 220, andtransmit those inputs to backend visualization system 210 forprocessing. Examples of inputs include but are not limited tomanipulation commands, navigation commands, and other interactioncommands related to the displayed data. In an embodiment, view interface221 does not include any capability to process the inputs but merelyacts as a conduit for transferring user inputs to backend visualizationsystem 210. In an embodiment, view controller 212 receives the inputsprovided from view interface 221 and translates the inputs to commandsthat may be understood by model 211.

View interface 221 provides access to multiple user interfaces havingdifferent view formats such as 2D interface 222, 3D interface 223, andVR interface 224. View interface 221 can provide these view formatssimultaneously using the same data set from a data source throughdata-binding between view interface 221 and view controller 212. Inother words, instead of implementing a specific view controller on userdevice 220 to handle each view format (i.e., one view controller for 2Dinterface 222, 3D interface 223, and VR interface 224), shifting viewcontroller 212 to backend visualization system 210 at a backend device(e.g., backend device 110) enables user interface architecture 200 isable to employ a single view controller 212 to handle a plurality if notall view formats.

View interface 221 uses data binding to establish a connection to any of2D interface 222, 3D interface 223, and VR interface 224 and thecorresponding adapters within view interface 221. For example, 2Dinterface 222 may bind with data through 2D adapter 213; 3D interface223 may bind with data through 3D adapter 214, and VR interface 224 maybind with data through VR adapter 215. In an embodiment, there may beone adapter per view format. For example, two different 2D views may use2D interface 222 while two different 3 views may use 3D interface 223.The role of each adapter is to support the data binding capabilities ofits respective view format and to implement the client portion ofcommunication channel 230.

In an embodiment, each adapter in view interface 221 may have access tothe same data set which obviates the need to store data in differentformats for each view format. Instead, each adapter is responsible fortranslating the data set into a format that can be used by thecorresponding view format of view interface 221.

As noted above, data binding may refer to connecting user interfaceelements of the various views to data at a data source where viewcontroller 212 enables seamless communication between view interface 221and the data source. Accordingly, establishing a connection may involvethe user interface elements subscribing to data notifications associatedwith data elements from the data source. When the data element changesvalue, a data notification may be generated and any user interfaceelements that are bound to that data element may reflect the changesautomatically. Those changes may be transmitted through communicationchannel 230. In addition to transferring data changes and notifications,communication channel 230 may also be responsible for transmitting userinputs from view interface 221 to view controller 212.

Because of this implementation, view interface 221 may request one ormore different view formats for its user interface. For example, 2Dinterface 222, 3D interface 223, and/or VR interface 224 may implement adata binding procedure to specify data that is to be transported to andfrom backend visualization system 210. In an embodiment, the databinding procedure may include a request from 2D interface 222, 3Dinterface 223, and/or VR interface 224 to be bound to one or more dataelements at a data source. View controller 212 may receive the requestand facilitate the connection between the requesting view interface andthe requested data elements. The requested data elements or data set maybe the same for 2D interface 222, 3D interface 223, and/or VR interface224. That is, more than one view interface may be bound to the same dataset which provides for a common view to the same data set across thedifferent view formats.

FIG. 3 is a flowchart illustrating a method of driving multiple userinterfaces using a backend view controller, according to someembodiments. Method 300 can be performed by processing logic that cancomprise hardware (e.g., circuitry, dedicated logic, programmable logic,microcode, etc.), software (e.g., instructions executing on a processingdevice), or a combination thereof. It is to be appreciated that not allsteps may be needed to perform the disclosure provided herein. Further,some of the steps may be performed simultaneously, or in a differentorder than shown in FIG. 3, as will be understood by a person ofordinary skill in the art.

As a non-limiting example with regard to FIGS. 1 and 2, the steps ofmethod 300 may be performed by components of data source 120, backendvisualization system 131 and user device 150 a or some combinationthereof. While method 300 will be discussed below as being performed byone or more of these components, other components may store codenecessary to execute some or all of the steps of method 300. Method 300will be described with reference to FIGS. 1 and 2. However, method 300is not limited to that example embodiment

In 302, view interface may receive a view format request that includes arequested data set from a data source. For example, view interface 221may receive a view format request based on user input provided to userdevice 220 to retrieve a data set from data source 120. View interface221 transmits the view format request, via communication channel 230, toview controller 212 in backend visualization system 210. The view formatrequest may specify a view format, such as a two-dimensional interface,three-dimensional interface, and/or virtual reality interface along withthe requested data set to be retrieved from the data source. In anembodiment, the requested data set is not specific for a specific viewformat but represents data without any visualization information, suchas the layout. Visualization of the requested data set may be performedby view interface 221. In an embodiment, the view format request mayonly specify the requested data set. The view format may be considered atype of view for the user interface.

In 304, the view controller may request a data set to be retrieved fromthe data source. For example, backend visualization system 210, afterreceiving the request from view interface 151 a, may request therequested data set from data source 120. The data set may then be heldby backend visualization system 210 until the data binding procedure iscompleted.

In 306, the view controller may expose the data set to the requestingview interface to enable binding. For example, view controller 212 mayexpose the data set from a data source to view interface 221. Viewcontroller 212 may transmit an indication to view interface 221 viacommunication channel 230 that the data set is exposed and ready forbinding.

In 308, view interface may update data bindings with the exposed dataset based on the view format specified by the user input. For example,the specific user interface (e.g., 2D interface 222, 3D interface 223,and/or VR interface 224) of view interface 221 may bind with the exposeddata set through the corresponding adapter. In an embodiment, thecorresponding adapter may generate a reference to the requested data setthat will connect it to the requesting user interface of view interface221.

In 310, view interface may display the bound data in the view formatspecified by the user input. For example, if 2D interface 222 requestedthe data set, 2D interface 222 will display the bound data set on userdevice 220.

Various embodiments may be implemented, for example, using one or morewell-known computer systems, such as computer system 400 shown in FIG.4. One or more computer systems 400 may be used, for example, toimplement any of the embodiments discussed herein, as well ascombinations and sub-combinations thereof.

Computer system 400 may include one or more processors (also calledcentral processing units, or CPUs), such as a processor 404. Processor404 may be connected to a communication infrastructure or bus 406.

Computer system 400 may also include customer input/output device(s)403, such as monitors, keyboards, pointing devices, etc., which maycommunicate with communication infrastructure 406 through customerinput/output interface(s) 402.

One or more of processors 404 may be a graphics processing unit (GPU).In an embodiment, a GPU may be a processor that is a specializedelectronic circuit designed to process mathematically intensiveapplications. The GPU may have a parallel structure that is efficientfor parallel processing of large blocks of data, such as mathematicallyintensive data common to computer graphics applications, images, videos,etc.

Computer system 400 may also include a main or primary memory 408, suchas random access memory (RAM). Main memory 408 may include one or morelevels of cache. Main memory 408 may have stored therein control logic(i.e., computer software) and/or data.

Computer system 400 may also include one or more secondary storagedevices or memory 410. Secondary memory 410 may include, for example, ahard disk drive 412 and/or a removable storage device or drive 414.Removable storage drive 414 may be a floppy disk drive, a magnetic tapedrive, a compact disk drive, an optical storage device, tape backupdevice, and/or any other storage device/drive.

Removable storage drive 414 may interact with a removable storage unit418. Removable storage unit 418 may include a computer usable orreadable storage device having stored thereon computer software (controllogic) and/or data. Removable storage unit 418 may be a floppy disk,magnetic tape, compact disk, DVD, optical storage disk, and/any othercomputer data storage device. Removable storage drive 414 may read fromand/or write to removable storage unit 418.

Secondary memory 410 may include other means, devices, components,instrumentalities or other approaches for allowing computer programsand/or other instructions and/or data to be accessed by computer system400. Such means, devices, components, instrumentalities or otherapproaches may include, for example, a removable storage unit 422 and aninterface 420. Examples of the removable storage unit 422 and theinterface 420 may include a program cartridge and cartridge interface(such as that found in video game devices), a removable memory chip(such as an EPROM or PROM) and associated socket, a memory stick and USBport, a memory card and associated memory card slot, and/or any otherremovable storage unit and associated interface.

Computer system 400 may further include a communication or networkinterface 424. Communication interface 424 may enable computer system400 to communicate and interact with any combination of externaldevices, external networks, external entities, etc. (individually andcollectively referenced by reference number 428). For example,communication interface 424 may allow computer system 400 to communicatewith external or remote devices 428 over communications path 426, whichmay be wired and/or wireless (or a combination thereof), and which mayinclude any combination of LANs, WANs, the Internet, etc. Control logicand/or data may be transmitted to and from computer system 400 viacommunication path 426.

Computer system 400 may also be any of a personal digital assistant(PDA), desktop workstation, laptop or notebook computer, netbook,tablet, smart phone, smart watch or other wearable, appliance, part ofthe Internet-of-Things, and/or embedded system, to name a fewnon-limiting examples, or any combination thereof.

Computer system 400 may be a client or server, accessing or hosting anyapplications and/or data through any delivery paradigm, including butnot limited to remote or distributed cloud computing solutions; local oron-premises software (“on-premise” cloud-based solutions); “as aservice” models (e.g., content as a service (CaaS), digital content as aservice (DCaaS), software as a service (SaaS), managed software as aservice (MSaaS), platform as a service (PaaS), desktop as a service(DaaS), framework as a service (FaaS), backend as a service (BaaS),mobile backend as a service (MBaaS), infrastructure as a service (IaaS),etc.); and/or a hybrid model including any combination of the foregoingexamples or other services or delivery paradigms.

Any applicable data structures, file formats, and schemas in computersystem 400 may be derived from standards including but not limited toJavaScript Object Notation (JSON), Extensible Markup Language (XML), YetAnother Markup Language (YAML), Extensible Hypertext Markup Language(XHTML), Wireless Markup Language (WML), MessagePack, XML User InterfaceLanguage (XUL), or any other functionally similar representations aloneor in combination. Alternatively, proprietary data structures, formatsor schemas may be used, either exclusively or in combination with knownor open standards.

In some embodiments, a tangible, non-transitory apparatus or article ofmanufacture comprising a tangible, non-transitory computer useable orreadable medium having control logic (software) stored thereon may alsobe referred to herein as a computer program product or program storagedevice. This includes, but is not limited to, computer system 400, mainmemory 408, secondary memory 410, and removable storage units 418 and422, as well as tangible articles of manufacture embodying anycombination of the foregoing. Such control logic, when executed by oneor more data processing devices (such as computer system 400), may causesuch data processing devices to operate as described herein.

Based on the teachings contained in this disclosure, it will be apparentto persons skilled in the relevant art(s) how to make and useembodiments of this disclosure using data processing devices, computersystems and/or computer architectures other than that shown in FIG. 4.In particular, embodiments can operate with software, hardware, and/oroperating system implementations other than those described herein.

It is to be appreciated that the Detailed Description section, and notany other section, is intended to be used to interpret the claims. Othersections can set forth one or more but not all exemplary embodiments ascontemplated by the inventor(s), and thus, are not intended to limitthis disclosure or the appended claims in any way.

While this disclosure describes exemplary embodiments for exemplaryfields and applications, it should be understood that the disclosure isnot limited thereto. Other embodiments and modifications thereto arepossible, and are within the scope and spirit of this disclosure. Forexample, and without limiting the generality of this paragraph,embodiments are not limited to the software, hardware, firmware, and/orentities illustrated in the figures and/or described herein. Further,embodiments (whether or not explicitly described herein) havesignificant utility to fields and applications beyond the examplesdescribed herein.

Embodiments have been described herein with the aid of functionalbuilding blocks illustrating the implementation of specified functionsand relationships thereof. The boundaries of these functional buildingblocks have been arbitrarily defined herein for the convenience of thedescription. Alternate boundaries can be defined as long as thespecified functions and relationships (or equivalents thereof) areappropriately performed. Also, alternative embodiments can performfunctional blocks, steps, operations, methods, etc. using orderingsdifferent than those described herein.

References herein to “one embodiment,” “an embodiment,” “an exampleembodiment,” or similar phrases, indicate that the embodiment describedcan include a particular feature, structure, or characteristic, butevery embodiment can not necessarily include the particular feature,structure, or characteristic. Moreover, such phrases are not necessarilyreferring to the same embodiment. Further, when a particular feature,structure, or characteristic is described in connection with anembodiment, it would be within the knowledge of persons skilled in therelevant art(s) to incorporate such feature, structure, orcharacteristic into other embodiments whether or not explicitlymentioned or described herein. Additionally, some embodiments can bedescribed using the expression “coupled” and “connected” along withtheir derivatives. These terms are not necessarily intended as synonymsfor each other. For example, some embodiments can be described using theterms “connected” and/or “coupled” to indicate that two or more elementsare in direct physical or electrical contact with each other. The term“coupled,” however, can also mean that two or more elements are not indirect contact with each other, but yet still co-operate or interactwith each other.

The breadth and scope of this disclosure should not be limited by any ofthe above-described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

What is claimed is:
 1. A computer implemented method, comprising: receiving, at a view interface system, a data set request to display a data set in a view format; exposing, by a backend view controller, a plurality of functions that may be performed on the data set, wherein the plurality of functions includes the data set request and a user input function; transmitting, to the backend view controller, the data set request via a communications channel, wherein the backend view controller is located on a backend device remote from the view interface system, and wherein the backend view controller maintains a first state of the data set, wherein the backend view controller comprises a plurality of view adapters including a view adapter and a second view adapter, and wherein the view adapter corresponds to the view format and the second view adapter corresponds to a second view format; receiving, at the view interface system via the communications channel from the backend view controller, an indication the data set is exposed by the backend view controller; performing, based on the indication, two-way data binding of the data set to interface objects associated with the view format and provided by the view interface system to form a user interface based on the view format, wherein the two-way data binding further comprises: facilitating, by the backend view controller, a connection between the data set and the interface objects; receiving, from the backend view controller by the view interface system, a first update when a property of the data set is modified, wherein the first update represents a delta between the first state and a second state of the data set and wherein the second state reflects a modification to the property of the data set; and transmitting, from the view interface system to the backend view controller, a second update when an interface object of the interface objects is modified, wherein the second update results in updating the second state to a third state of the data set; displaying, by the view interface system, the user interface; transmitting, by the view interface system for processing by the backend view controller, the user input function associated with the displayed data; translating the user input function to a command for manipulating the displayed data; receiving, at the view interface system, a second data set request to display the data set in the second view format, wherein the second view format is different from the view format, and wherein the view format is a two-dimensional interface and the second view format is one of a three-dimensional interface or a virtual reality interface, and the view interface system transmits to the backend view controller requests associated with the view format and the second view format; transmitting, to the backend view controller, the second data set request via the communications channel; receiving, at the view interface system via the communications channel from the backend view system, the data set; performing, by the view interface system, another two-way data binding of the data set to second interface objects associated with the second view format to form a second user interface based on the second view format; displaying, by the view interface system, the second user interface; receiving, by the view interface system, a data notification regarding a change to at least one data element in the data set; updating, based on the data notification, the user interface to reflect the change to the at least one data element; and updating, based on the data notification, a second user interface to reflect the change to the at least one data element.
 2. The method of claim 1, wherein the view format comprises at least one of a two-dimensional interface, a three-dimensional interface, or a virtual reality interface.
 3. The method of claim 1, the performing further comprising: connecting the view interface system to the backend view controller through the view adapter to provide the view format; and connect the view interface system to the backend view controller through the second view adapter to provide the second view format.
 4. A system, comprising: a memory; and at least one processor coupled to the memory and configured to: receive, at a view interface system, a data set request to display a data set in a view format; expose, by a backend view controller, a plurality of functions that may be performed on the data set, wherein the plurality of functions includes the data set request and a user input function; transmit, to the backend view controller, the data set request via a communications channel, wherein the backend view controller is located on a backend device remote from the view interface system, and wherein the backend view controller maintains a first state of the data set, wherein the backend view controller comprises a plurality of view adapters including a view adapter and a second view adapter, and wherein the view adapter is the view format and the second view adapter corresponds to a second view format; receive, at the view interface system via the communications channel from the backend view controller, an indication the data set is exposed by the backend view controller; perform, based on the indication, two-way data binding of the data set to interface objects associated with the view format and provided by the view interface system to form a user interface based on the view format, wherein the two-way data binding further comprises: facilitating, by the backend view controller, a connection between the data set and the interface objects; receiving, from the backend view controller by the view interface system, a first update when a property of the data set is modified, wherein the first update represents a delta between the first state and a second state of the data set and wherein the second state reflects a modification to the property of the data set; and transmitting, from the view interface system to the backend view controller, a second update when an interface object of the interface objects is modified, wherein the second update results in updating the second state to a third state of the data set; display, by the view interface system, the user interface in the view format; and transmit, by the view interface system to the backend view controller, the user input function associated with the displayed data; translate the user input function to a command for manipulating the displayed data; receive, at the view interface system, a second data set request to display the data set in the second view format, wherein the second view format is different from the view format, and wherein the view format is a two-dimensional interface and the second view format is one of a three-dimensional interface or a virtual reality interface, and the view interface system transmits to the backend view controller requests associated with the view format and the second view format; transmit, to the backend view controller, the second data set request via the communications channel; receive, at the view interface system via the communications channel from the backend view system, the data set; perform, by the view interface system, another two-way data binding of the data set to second interface objects associated with the second view format to form a second user interface based on the second view format; display, by the view interface system, the second user interface; receive, by the view interface system, a data notification regarding a change to at least one data element in the data set; update, based on the data notification, the user interface to reflect the change to the at least one data element; and update, based on the data notification, a second user interface to reflect the change to the at least one data element.
 5. The system of claim 4, wherein the view format comprises at least one of a two-dimensional interface, a three-dimensional interface, or a virtual reality interface.
 6. The system of claim 4, wherein the at least one processor is further configured to: connect the view interface system to the backend view controller through the at least one view adapter to provide the view format; and connect the view interface system to the backend view controller through the second view adapter to provide the second view format.
 7. A non-transitory computer-readable device having instructions stored thereon that, when executed by at least one computing device, cause the at least one computing device to perform operations comprising: receiving, at a view interface system, a data set request to display a data set in a view format; exposing, by a backend view controller, a plurality of functions that may be performed on the data set, wherein the plurality of functions includes the data set request and a user input function; transmitting, to a backend view controller, the data set request via a communications channel, wherein the backend view controller is located on a backend device remote from the view interface system, and wherein the backend view controller maintains a first state of the data set, wherein the backend view controller comprises a plurality of view adapters including a view adapter and a second view adapter, and wherein the view adapter is the view format and the second view adapter corresponds to a second view format; receiving, at the view interface system via the communications channel from the backend view controller, an indication the data set is exposed by the backend view controller; performing, based on the indication, two-way data binding of the data set to interface objects associated with the view format and provided by the view interface system to form a user interface based on the view format, wherein the two-way data binding further comprises: facilitating, by the backend view controller, a connection between the data set and the interface objects; receiving, from the backend view controller by the view interface system, a first update when a property of the data set is modified, wherein the first update represents a delta between the first state and a second state of the data set and wherein the second state reflects a modification to the property of the data set; and transmitting, form the view interface system to the backend view controller, a second update when an interface object of the interface objects is modified, wherein the second update results in updating the second state to a third state of the data set; displaying, by the view interface system, the user interface; transmitting, by the view interface system for processing by the backend view controller, the user input function associated with the manipulating the displayed data; translating the user input function to a command for manipulating the displayed data; receiving, at the view interface system, a second data set request to display the data set in the second view format, wherein the second view format is different from the view format, and wherein the view format is a two-dimensional interface and the second view format is one of a three-dimensional interface or a virtual reality interface, and the view interface system transmits to the backend view controller requests associated with the view format and the second view format; transmitting, to the backend view controller, the second data set request via the communications channel; receiving, at the view interface system via the communications channel from the backend view system, the data set; performing, by the view interface system, another two-way data binding of the data set to second interface objects associated with the second view format to form a second user interface based on the second view format; displaying, by the view interface system, the second user interface; receiving, by the view interface system, a data notification regarding a change to at least one data element in the data set; updating, based on the data notification, the user interface to reflect the change to the at least one data element; and updating, based on the data notification, a second user interface to reflect the change to the at least one data element.
 8. The non-transitory computer-readable device of claim 7, wherein the view format comprises at least one of a two-dimensional interface, a three-dimensional interface, or a virtual reality interface.
 9. The non-transitory computer-readable device of claim 7, the operations further comprising; connecting the view interface system to the backend view controller to the view adapter to provide the view format; and connect the view interface system to the backend view controller through the second view adapter to provide the second view format.
 10. The non-transitory computer-readable device of claim 8, the operations further comprising: receiving, by the view interface system, a data notification regarding a change to at least one data element in the data set; and updating, based on the data notification, the user interface to reflect the change to the at least one data element. 